This is a preliminary release, so this readme isn't very extensive. See the "3dfx.txt" file for 3dfx specific information. We aren't finished with optimizing the 3dfx driver, but it is certainly good enough to play with. startup options --------------- -window Start up in a 640*480 window instead of going full screen -width <800 / 1024 / 1280> Go to a specific full screen resolution instead of the default 640*480. dynamic options --------------- gl_flashblend <0 or 1, defaults to 1> The dynamic light flashes can be replaced with a colored blend effect, which is much more efficient in most cases. gl_ztrick <0 or 1, defaults to 1> A slight speed benefit is gained by splitting the z buffer. On professional (24+ bit) cards this is allways fine, but on 16 bit cards you may occasionally see some pixels poke through a wall because of limited precision. gl_keeptjunctions <0 or 1, defaults to 0> A lot of triangles can be saved by not exactly fixing up colinear tjunction points, but this can cause single pixel errors at polygon borders. If you change this, you will have to restart the level. gl_texturemode Determines the OpenGL texture filters. Intergraph is the only one that really does all of these correctly. GL_NEAREST : point sampled, no mipmaps GL_LINEAR_MIPMAP_NEAREST : bilinear plus mipmaps GL_LINEAR_MIPMAP_LINEAR : trilinear interpolation gl_earlyswap <0 or 1, defaults to 1> This determines when page flips are done, which has different effects on different buffering schemes. Intergraph users should set this to 0, 3dfx users should leave it at 1. Intergraph hardware ------------------- The reactor does not support OpenGL at this time, and vquake is far more optimized for that hardware anyway. The intense-3D can run glquake, but only at about 8-10 fps due to limited (15 mpix) fill rate. It does run in 24 bit color and you can turn on trilinear with little additional penalty, though. It runs pretty good on realizm boards, except when a lot of lights are flickering. The next release of intergraph's GL driver will run glquake significantly better -- we uncovered a buffering issue that was keeping the hardware from performing up to its potential. 3DLabs hardware --------------- You really shouldn't run glquake on 3dlabs hardware right now. Exiting from a full screen game crashes NT. You can still run with -window, but it isn't really playable. A glint-TX will properly execute glquake, but it peaks around 5 fps due to a very low fill rate, and it goes horribly slow during texture uploads for dynamic lights. A permedia board does not support the proper blending modes to run glquake normally. You can get it to work with "glquake -lm_4 +r_flashblend 0", but it will be way slow. I think it is actually possible to get a permedia running glquake at an almost decent rate (high teens, 512*384 res) if 3dlabs optimizes some aspects of their OpenGL driver. Other hardware -------------- DEC powerstorms should work the same as intergraph realizms, but DEC forgot to enable the texture object extensions in their current drivers. I will release NT/alpha compiled versions as soon as there is an apropriate hardware board to run it on (glint boards aren't good enough). Dynamic pictures' oxygen boards are not even close to working. They have VERY slow texturing rates, and don't support texture binding. The Real3D chips should work well as soon as they get their NT 4.0 drivers done. There are several other chips coming out this year that will be plenty powerfull enough. I am willing to provide technical assistance to any IHVs interested in optimizing their OpenGL drivers. John Carmack 1/21/97